fix(web): resync model in set osk() (as used by Server)#16127
Conversation
When a new OSK is attached, we need to set its active keyboard and lexical model. These are undocumented API contracts between Keyman Engine for Web and Keyman Developer Server, so this appears to have changed in v.19 for keyboards (although the sync is also necessary for v.18). Fixes: #15217 Test-bot: skip
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
Yes, I think it would be good to investigate what changed that causes this different behaviour. |
A bisect showed that this regressed in 19.0.241 with the merge of #16015. That's going to be hard to bisect further! I will attempt to step-through the source. |
| // After attaching a new OSK, we also need to set the OSK's active keyboard | ||
| // and model | ||
| newOSK.activeKeyboard = keyman.contextManager.activeKeyboard; // Note: undocumented KeymanWeb API refs on both sides |
There was a problem hiding this comment.
After #16156 lands, activeKeyboard is properly set automatically again.
| // After attaching a new OSK, we also need to set the OSK's active keyboard | |
| // and model | |
| newOSK.activeKeyboard = keyman.contextManager.activeKeyboard; // Note: undocumented KeymanWeb API refs on both sides | |
| // After attaching a new OSK, we also need to set the OSK's active model |
@ermshiperete, should model attachment be resolved web-side also?
|
Returned to draft in order to discuss whether model fix should be done in Keyman Engine |
…nc-model-after-device-switch
…t osk After review, it is better to do the sync of the model banner in KeymanWeb `set osk()` than in the client of the API. The client should be able to assign a new OSK and have it "just work" without needing to attach things to it. Fixes: #15217
mcdurdin
changed the title
set osk() (as used by Server)
Yes, better to make this change in the web source. @jahorton FYI. |
|
Changes in this pull request will be available for download in Keyman version 19.0.253-alpha |
4 participants
When a new OSK is attached, we need to set its active keyboard and lexical model. These are undocumented API contracts between Keyman Engine for Web and Keyman Developer Server, so this appears to have changed in v.19 for keyboards (although the sync is also necessary for v.18).
@ermshiperete the behaviour for active keyboard has changed between v.18 and v.19. In v.18, switching device, the new osk would receive the active keyboard automatically. But in v.19, we need to assign it in Server. I think we may need to track where the change originates in case it impacts other use cases?
Fixes: #15217
Test-bot: skip